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® (57) Abstract: A method is disclosed by which a user of a roaming mobile station can procure services and goods from a content 
O provider at a visiting site. The content provider establishes contact with a mobile e-commerce server, the visited MeC server. The 
^ visited MeC server directs the request to the users home MeC server. The home MeC server performs the authentication of the user. 
!^ In this way security relevant information is not revealed to the visited MeC server. 
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Roaming for Mobile ©-Commerce 
Technical Field 

This invention is applicable for Mobile e-Commerce. 
Technical Background 
Mobile e-Commerce 

Mobile e-Commerce is commerce made available to the mobile 
user through mobile devices such as mobile phones, PDA, 
etc. The mobile user has the possibility to make a bet, 
play a game, pay bills, perform a transaction, buy stocks, 
buy and pay securely using their mobile device. 

Due to the physical limitations of the mobile devices such 
as processing power, memory size, battery lifetime, etc. it 
is common to have a Mobile e-Commerce (MeC) server to as- 
sist in the security and payment processes. Figure 1 shows 
an example of a Mobile e-Commerce system, which consists 
of: 

• Mobile devices 

• A Mobile e-Commerce Server 

• Financial Institutions 

• Merchant or Content Provider 

In general a user browses to a merchant or content provider 
site using their mobile device. They are presented with op- 
tions and select goods or services to be purchased. At some 
stage they will wish to ''check out" and pay for these 
selected items. The content provider diverts the request to 
the MeC Server. The MeC server maintains relevant user in- 
formation in order to authenticate, and get payment ap- 
proval. It then contacts the Financial Institution (e.g. 
Credit Card Company, bank, etc.) to get payment clearance. 
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On a positive answer from the Financial Institution, the 
MeC server will inform the content provider to proceed. 
Depending on the nature of the merchandise, it could be de- 
livered directly to the user, be picked up by the user or 
s be shipped by post later. The general flow is shown in 
Figure 2 . 

It is important to note that in this scenario, both the 
user and the content provider are registered in the Mobile 
e-Commerce server. Obviously the Financial Institution has 
io agreements with the Mobile e-Cornmerce service provider and 
the content provider for payment clearance. This environ- 
ment can be regarded as the Home Service Area. How the user 
access this service area, is outside the scope of this 
document . 

15 The Problem Area 

The substance of Mobile e-Commerce lies on the mobility of 
the user. It should be possible for a mobile user to access 
Mobile e-Commerce services whenever and wherever he/she is, 
both nationally and internationally. 

20 Currently, when roaming, the mobile user can communicate 
with their Home Mobile e-Commerce Service Area. They can 
still make a bet, pay a bill or perform a transaction. How- 
ever, when it comes to purchasing it is likely that he/she 
wants to buy things that are local at the visiting site. 

25 For example internationally, then it is quite obvious that 
they will want to purchase movie tickets at a visited 
cinema, and not their home theatre. It is likely that this 
cinema or visited ticket provider will not have an estab- 
lished agreement with the Home Mobile e-Commerce Service 

30 Provider. 

On the other hand, the visited ticket provider probably has 
the necessary agreements with the Visiting Mobile e-Com- 
merce Service Provider but cannot offer services to the 



Printed from Mimosa 05/10/14 12:26:34 Page: 4 



WO 02/063528 



3 



PCT/SEO 1/027 19 



roaming mobile user since the service provider does not 
have necessary subscription details such as: 

• For security purposes: Cryptographic Keys, Digital 
Certificates etc. These can be used for identifying the 
subscriber, generating and/or verifying Digital Signatures 

• For payment purposes: Credit Card details, Bank 
Account numbers etc. These can be used for completing pay- 
ment transactions, 

The situation is depicted in Figure 3. The current solution 
does not allow a mobile user away from home to access both 
the Home Mobile e-Commerce service and Visiting Mobile e- 
Commerce services. This is a major limitation of present 
systems . 

Related prior art 

International patent application W09944165 discloses a sys- 
tem for e-Commerce on the Internet, enabling customers to 
pay for services and goods from prepaid accounts. The sys- 
tem is based on the use of modular transaction servers 
(TxS) . The TxS includes among other an input device for 
receiving requests for a service from end-users, a service 
device rendering the requested service and an account de- 
vice for keeping track of the users balances. 

In a roaming situation, two TxS devices are involved. The 
first device, identified as a foreign TxS, is the place 
where the end-user initiates the transaction. The second 
device, identified as the home TxS, holds the business 
information for the pre-paid account. The home TxS is re- 
quested by the foreign TxS to retrieve the PIN information 
and update the account. 

W09944165 relates to e-Commerce on the Internet and never 
discusses the mobile domain or the implications of roaming 
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within this domain. The solution is restricted to prepaid 
transactions . 

A major weakness with this system is the low security level 
offered, due to the exchange of PIN data. This assumes a 

s trust level between the home TxS and the foreign TxS . It is 
assumed that a user will automatically trust the foreign 
TxS, and provide secret information, such as a PIN, to this 
foreign server. In the mobile world it is very likely that 
the home operator and the foreign operator have no trust 

io relationship. This makes this solution less feasible in a 
mobile communication network. 

Further, W09944165 mentions nothing on how to identify the 
home server, it is assumed that the foreign server knows 
this server. 

is The Invention 

Brief description 

•h 

The present invention is aiming at removing the limitations 
mentioned above by introducing roaming capability in the 
Mobile e-Commerce systems. 

20 According to the invention, if an MeC server is approached 
by an unknown user, it will find the users home MeC server 
and redirect him to that server. The home MeC server will 
then take care of the security verification and payment 
processes. Afterwards, the user is redirected to the 

2s visited MeC server to complete the transaction. By this ar- 
rangement, sensitive information is communicated directly 
between the user and his home MeC server, and not revealed 
to foreign parties. The invention comprises: 

• A roaming capability module for Mobile e-Commerce 

30 Servers. The roaming module can be implemented as a plug-in 
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to existing e-Commerce servers, and is thereby independent 
of the e-Commerce server. 

• A method for home server location i.e. to find the 
Home Mobile e-Commerce server of a user. 

• An interconnection protocol to complete payment 
and security transactions. 

The scope of the present invention is as defined in the ap- 
pended patent claims. 

An embodiment of the present invention will now be 
described in reference to the appended drawings, in which: 

Fig. 1 shows a simplified overview of a mobile e-Commerce 
system (prior art) , 

Fig. 2 shows the general payment flow in the mobile e-Com- 
merce system depicted in Fig. 1. 

Fig. 3 shows how roaming is blocked in a system according 
to Fig. 1. 

Fig. 4 is a general flow diagram of a procedure for home 
server location in a system according to the present inven- 
tion . 

: Fig. 5 relates to the interconnection protocol used for 
'"security and payment requests between the foreign and home 
server in a system according to the present invention, and 
shows the general flow diagram for such a request. 

Fig. 6 is a flow diagram showing the payment flow in a 
roaming situation . 
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Detailed description of the individual components in a sys- 
tem according to the invention 

Roaming Capability module 

The roaming capability module is a module on the Mobile e- 
Commerce server that maintains details for other Mobile e- 
Commerce servers. This can be partner servers, i.e. servers 
of which the operators have established a mutual agreement. 
However, such a partnership is not mandatory, but will be 
assumed in the following discussion. In the module, the 
following details are stored: 

• Name: An identifier for the partner service provider. 

• Access Address: This is a server address that can be 
addressed from another server. This may be an IP ad- 
dress, hostname and/or a URL. 

• Country: This identifies in which country the remote 
Mobile e-Commerce server is located. 

• Country Code: This is the international country code 
prefix of the remote server subscribers, e.g. the in- 
ternational prefix for Norway is 47. 

• Local Prefix: This is a list of prefixes that the remote 
server accepts request for. The local prefix helps in 
reducing the search if many MeC servers exist within a 
single country. 

The roaming capability module is connected to an inter- 
national network, such as the Internet (or for large corpo- 
rations, an Intranet) . In this way it can make requests to 
remote Mobile e-Commerce servers. 
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Home Server Location 

When an e-Commerce server is requested to fulfil a transac- 
tion for an unknown subscriber, it can try to identify the 
Home MeC server of that subscriber. The Roaming Capability 
Module can make a roamUserReques t to each of the partner 
Mobile e-Commerce servers. Using an intelligent search to 
reduce the partner list may reduce the number of 
roamUserRequest messages sent. Various methods can be used 
to reduce the search area, for example the subscribers 
phone number may identify a geographical area that should 
be requested first, this can be further reduced using the 
local prefix . 

roamUserRequest 

The roamUserRequest requests the remote Mobile e-Commerce 
server to respond indicating if they will accept requests 
of a specif ic . type for the subscriber. The roamUserRequest 
contains at least: 

• A subscribers identity such as their phone number, 
and 

• The request type, such as payment, digital signa- 
ture etc. 

The request type relates to the purpose of the transaction, 
i.e. to pay for a service or goods, gain access to sensi- 
tive information (in which case it may be necessary to 
verify the identity of the user or establish a secure com- 
munication channel), sign an agreement (a digital certifi- 
cate is needed), or start a new service. 

On receipt of a roamUserRequest the remote Mobile e-Com- 
merce server responds with a roamUserResponse. The 
roamUserResponse contains : 



Printed from Mimosa 05/10/14 12:26:46 Page: 9 



WO 02/063528 



8 



PCT/SE01/02719 



• The subscriber identity 

• The request type 

• Accept or Reject 

• A list of additional information available to for the 
subscriber e.g. Payment methods available. 

Figure 4 shows the general flow for Home Server Location. 

In order to increase security the roamUserRequest and 
roamUserResponse may be digitally signed by the MeC server. 
In this way the receiving server can be more certain that 
the originating request is from a valid MeC server. 

Once the Roaming Capability Module identifies the Home Mo- 
bile e-Commerce server then both servers can authenticate 
to avoid rogue systems and establish a secure communication 
channel. This authentication and secure communication is 
outside the scope of this description, but may use existing 
solutions such as SSL or TLS . 

Interconnection protocol 

The Interconnection Protocol provides for Security and Pay- 
ment Requests . 

Security 

One of the primary concerns with security is revealing 
secret information to a third party that may not be 
trusted. As a result it is important that all security re- 
quests are handled through the Home Mobile e-Commerce 
Server. To achieve this the user must be directed to their 
Home Mobile e-Commerce Server, and the result must be made 
available to the Visited Mobile e-Commerce Server. 



Printed from Mimosa 05/10/14 12:26:48 Page: 10 



WO 02/063528 



9 



PCT/SE01/02719 



This procedure varies somewhat in dependence of the request 
type, i.e. if the desired action is a payment or some other 
service. This service maybe requesting a digital signature 
to access sensitive information, such as a bank account 
balance, or subscribing to a new service, which requires 
signing of a service agreement. We will first describe the 
procedure followed when the request type is of some other 
type than payment. 

Figure 5 shows the general flow for such a request. 
Following the diagram: 

Steps 1-5 identify the Home Server, as described in the 
preceding chapter . 

Steps 6-7 get a contract that will be used for Authenti- 
cation or Digital Signing from the content provider 

Step 8 delivers the contract to the Home Mobile e-Commerce 
Server. This communication uses the secure link established 
in Steps 1-5 

Step 9 is a message to direct the user to their Home Mobile 
e-Commerce Server 

Step 10. The user makes the security request directly to 
their Home MeC Server. Client-Server authentication maybe 
used here to provide a guarantee to the end-user that they 
are communicating with the correct MeC Server. How this is 
achieved is outside the scope of this description. 

Step 11. The Home MeC Server responds with the contract 

Step 12. The user enters their PIN 

Step 13. The security result ( securi tyResult ) is returned 
to the Home MeC Server 
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Step 14. The home MeC server verifies the security result 

Step 15. The Visited MeC server is notified of the result 

Step 16. The Content Provider is notified of the result 

Step 17. The end user is provided with a transaction re- 
ceipt, and an URL to continue browsing (18) . 

It is important to note that the secur i tyResult may vary 
depending on the request type and the Mobile Device capa- 
bilities : 

• Authentication 

If the requestType is authentication, then the 
roamSecurityResult will indicate whether or not the request 
was successful. 

• Delegated Digital Signing 

If the requestType is Digital Signature, then the Home MeC 
Server, may authenticate the user, and then using stored 
information generate the digital signature on the server. 

• End to End Digital Signing 

If the requestType is Digital Signature, or End-to-End 
Digital Signature and the Mobile Device supports digital 
signature generation, then the secur i tyResult will be the 
Digital Signature generated from the Mobile Device. The 
roamSecurityResult may be the same signature or contain 
additional information. E.g. converted from PKCS#1 to 
PKCS#7 using locally stored information. 
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Payment 

The following example shows the individual steps involved 
when the request type is payment. 

Figure 6 shows the Payment Flow when roaming. Again follow- 
ing the diagram: 

Steps 1-5 identify the Home Server, as described in the 
preceding chapter . 

Steps 6-7 get details of the payment from the content pro- 
vider, e.g. total value of the goods/service to be pur- 
chased . 

Steps 8-9. The roamUserResponse contains the payment types 
available for the end-user. Using this information, and 
local information on the Content Provider, it is possible 
for the Visited MeC Server, to identify a subset of avail- 
able payment types,, and present these to the end-user for 
selection. 

Step 10. The Visited MeC Server generates a contract for 
payment and delivers it to the Home MeC Server. This com- 
munication uses the secure link established in Steps 1-5. 

Step 11. A message to direct the user to their Home MeC 
Server . 

Step 12. The user makes a pay request directly to their 
Home MeC Server. Client-Server authentication maybe used 
here to provide a guarantee to the end-user that they are 
communicating with the correct MeC Server. How this is 
achieved is outside the scope of this description. 

Step 13. The Home MeC Server responds with the contract 

Step 14. The user enters their PIN 
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Step 15. The security result is returned to the Home MeC 
Server 

Step 16. The home MeC server verifies the security result 

Step 17. The Home MeC Server delivers the result to the 
5 Visited MeC Server. This result indicates if payment can 

continue. It also contains relevant information to complete 
the payment, e.g. the end-user credit card details. 

Steps 18-19. A message is delivered to verify the payment 
will be completed, and direct the end-user to the Visited 
io MeC Server. 

Steps 20A and 20B. The Payment is performed. This requires 
communication with both the Content Provider and the Finan- 
cial Institution. This is outside the scope of this 
description as there are many well know payment solutions 
is and flows . 

Step 21. The Home MeC Server is notified of the payment re- 
sult. 

Step 22. The end user is provided with a transaction re- 
ceipt and an URL to continue browsing (18). 

20 Advantages 

The advantages to this solution include: 

1. Security relevant information such as PIN numbers or 
private keys is never revealed. 

2 . Once a content provider has established connection to 
25 a Mobile e-Comrnerce Server, there is no additional 

work for the content provider to receive payments from 
roaming subscribers . 
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3. There is no additional complexity for the end user.. 
For example in the payment flow, Steps 12, 19 are 
slightly different. However, using for example the 
WAP, WML element 'onenter forward' , the end-user may 
s not notice the difference. 

Broadening 

It is possible that this could be broadened for a Server 
based Mobile Wallet. In this case the Home MeC server may 
contain the mobile wallet. Then in Steps 20A and 20B the 
10 payment flow would resolve the transfer of funds from the 
Mobile Wallet to the Content Provider account. 
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